Emergency session request handling in a network

ABSTRACT

The invention provides a method and system for handling a session request of a user equipment in a network comprising at least one supporting entity, in particular in a case where the user equipment is not allowed to initiate other session apart from specific session type. At least one of the supporting entities or another control entity is adapted to check whether or not the initiated session is actually continued as a session of the specific type. The session is forcibly terminated when detecting that it is not continued as such a session. A timer may be started when the user equipment attaches to the network for requesting a session, and the user equipment is detached from the network when not continuing with a session of the specific type within a defined time after attach.

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to a method and a system for handlingemergency sessions in a network, e.g. in a mobile network. In accordancewith a more detailed aspect, the invention relates to emergency supportfor barred or unidentifiable equipments such as a mobile or userequipment (UE).

Emergency sessions have to be supported even in special cases, e.g. forUEs not having a USIM (Universal Subscriber Identity Module), i.e.USIM-less UEs and for UEs which are not allowed to access the networke.g. due to barring. These UEs need to be allowed to access the networkbut only to setup emergency sessions. These UEs are only allowed toaccess the network and to activate PDP contexts for IMS (IP MultimediaSubsystem) related signalling (e.g. SIP, DHCP, DNS) and for the actualemergency session (IMS=IP Multimedia Subsystem; PDP=Packet DataProtocol; SIP=Session Initiation Protocol). Every other service shouldbe prohibited by the network.

If the UE then misbehaves and does not setup an emergency session butmay even try to setup another session, the network has to be able todetach the UE.

SUMMARY OF THE INVENTION

It is an object of the present invention to solve or alleviate the aboveproblems and to provide for preventing misuse of an e.g. emergencysession.

According to the present invention this object is achieved by a methodaccording to any of the independent method claims and/or a systemaccording to any of the independent system claims.

The invention provides a system and method for processing a sessionsetup procedure initiated by an user equipment in a network comprisingat least one supporting entity, wherein the user equipment is allowed toinitiate sessions of a first type or types and the user equipment is notallowed to initiate sessions of a second type or types. When the userequipment initiates a session, one of the supporting entities or anothercontrol entity checks whether or not the initiated session is actually asession of the first type, and the initiated session is terminated, ifdetecting that it is at least partially a session of the second type.

The session of the first type or one of the first types of sessions maybe an emergency session.

The invention further provides a system and method for detaching an userequipment from a network, wherein the user equipment is allowed toinitiate sessions of a first type or types and the user equipment is notallowed to initiate sessions of a second type or types. A time check isstarted when the user equipment attaches to the network for requesting asession of the first type or types, and the user equipment is detachedfrom the network when there is no bearer active for the session within adefined time after the attach.

A supporting entity may be provided to check whether one or more bearersare activated, and/or the session of the first type or types isconfirmed, within a defined time after attach, and the supporting entitydetaches the user equipment when no activation or confirmation has takenplace within the defined time.

The supporting entity preferably includes a timer set to the definedtime and being started when the user equipment attaches to the network.

In one of the preferred implementations of the invention, an interface,preferably Go interface, is used to validate whether the session isactually a session of the first type or types.

A control means or function, preferably P-CSCF/PCF, may be adapted tosend via the interface an indication whether the session is a session ofthe first type or types. The indication may be sent when a bearer isauthorized against the session, whereas, when the session is a sessionof the second type or types even if indicated in the bearer parameters,that the initiated session is a session of the first type or types, anentity rejects the bearer activation, or sends to another entity anindication indicating that the session is not a session of the firsttype or types, the user equipment then being detached from the network.The bearer may be a PDP context.

Detaching the user equipment may be requested via a server in case ofdetecting that the requested session is a session of the second type.The server can be a Home Subscriber Server (HSS).

A serving function, preferably S-CSCF, may indicate to the server thatthe user equipment has to be deregistered/detached from the network, theserver initiating a detach procedure by sending a message to thesupporting entity, such as SGSN.

One of the supporting entities may be adapted to detect whether a userequipment tries to misuse the session of the first type for a session ofthe second type.

A supporting entity, preferably GGSN, may be adapted to check that thetraffic is carried only between the user equipment and the authorizedpeer, and to drop all other traffic. When the supporting entity drops apacket, it deactivates the PDP context and/or controls the detach of theuser equipment.

The network allows an otherwise unauthorized UE, e.g. USIM-less andbarred UEs, to access the network but only to use specific services,e.g. to setup specific sessions such as emergency sessions. The networkchecks that these UEs are not using any other services of the network.If these UEs are trying to fake and use the network for other thanspecifically allowed servicesn, i.e. are misbehaving, they are detachedby the network.

The IMS knows whether a session under setup is actually a specificsession such as an emergency session and can indicate this to the PS(Packet-Switched) domain.

This invention proposes several mechanisms in case of misbehaving UEs.

A first implementation is that, if the PDP contexts are not activated(and the emergency session is not confirmed) within a certain time afterattach, the supporting entity, e.g. SGSN or MSC, detaches the UE. Thisrequires a timer in the supporting entity;

A second implementation is to use an interface, preferably the Gointerface to validate whether the session is actually an allowedsession, e.g. an emergency session. A control means or function in theapplication layer, e.g. P-CSCF/PCF in the IMS, indicates whether thesession is an allowed session. This indication can be sent from thecontrol means or function to the PS domain, e.g. to GGSN, when the PDPcontext is authorized against the session. If the session is not anallowed session even if indicated in the PDP context parameters, anentity, e.g. GGSN, rejects the PDP context activation. The supportingentity, e.g. SGSN, understands from the PDP context rejection that theUE was allowed to access the network just to setup an allowed sessionand the session is not an allowed session. The supporting entity thendetaches the UE.

An alternative solution is to introduce a clear indication betweensupporting entities, e.g. from GGSN to SGSN, that the session is not anallowed session, i.e. a session of a first type or types (e.g. with acause code ‘requested service incorrect’) and thus the UE should, andwill, be detached.

A third implementation is to request detaching the UE via a server, e.g.HSS (UMS/HLR). A serving function in the application layer, e.g. S-CSCFin the IMS, indicates to the server in the application layer, e.g. UMS,that the UE has to be deregistered/detached from the network. Theserver, e.g. UMS, passes this information to the PS domain, e.g. HLR.The HLR initiates the detach procedure by sending a message, e.g. CancelLocation, to the supporting entity, e.g. SGSN.

A further implementation is that the GGSN may know whether the UEmisuses the PDP contexts. For example, in case of SIP signaling, theGGSN checks that the traffic is carried only between the UE and theP-CSCF. All other traffic is dropped.

As another example, in case of an emergency session, the GGSN checksthat the traffic is carried only between the UE and the EC (EC=EmergencyCenter) or MGW (MGW=Media Gateway). All other traffic is dopped. If theGGSN drops packets, the UE is misusing the PDP context. The GGSN canthus deactivate the PDP context, and the SGSN can then detach the UE.

The first implementation is able to detect a variety of the misusecases.

A new cause code in GTP is preferably provided in the secondimplementation, where it is said that the supporting entity, e.g. SGSN,understands from PDP context rejection, that the UE was allowed toaccess the network just to establish an allowed session, e.g. anemergency session but the session is not an allowed session. That israther easy to implement. The Go interface option is one of thepreferred implementations since it is specified for the-communicationbetween the IMS and the PS domain. In the Go solution, e.g. theP-CSCF/PCF in the application layer preferably includes an indicationwhether the session is an allowed session to the decision message whichit. sends to the PS domain, e.g. GGSN. This is possible e.g. so that theGGSN includes in its request to the P-CSCF/PCF not only bindinginformation but an indication that the session is claimed to be anallowed session. In that way, the GGSN will ask for authorization of theallowed session. The P-CSCF/PCF then validates whether the session isactually an allowed session. Alternatively, the GGSN does not includeany indication in its request. But always the P-CSCF/PCF will check ifthe GGSN request is about an allowed session and will indicate that tothe GGSN. The PCF can receive this information from the P-CSCF and storeit per each session or session component. In the latter case, it is onlynecessary to make a change to COPS decision from the P-CSCF/PCF, withoutproviding any changes to the COPS request from the GGSN. This mechanismis easy to implement.

The invention (e.g. Go alternative) provides an efficient way toeliminate misbehaving UEs.

Further features and advantages of the present invention are defined inthe following.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic block diagram illustrating an embodiment of thepresent invention representing a simplified model for IP Multimedia,

FIG. 2 illustrates an embodiment for automatically detaching anequipment when not proceeding with the emergency session in a certaintime,

FIG. 3 shows another embodiment for automatically detaching an equipmentwhen not properly proceeding with the emergency session,

FIG. 4 illustrates a further embodiment for automatically detaching anequipment when not properly proceeding with the emergency session, and

FIG. 5 shows another embodiment for automatically detaching an equipmentwhen not properly proceeding with the emergency session.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION

FIG. 1 shows a basic schematic block diagram of an embodiment structureincorporating an implementation. of the present invention (IP MultimediaSubsystem).

The system of FIG. 1 includes one or more, usually a plurality of UEs(or MSs, Mobile Stations) 1, one or more supporting entities 2 such asSGSN 2 (or MSC/VLR), one or more gateway entities such as GGSN 3, aProxy Call State Control Function (P-CSCF) 4, a Home Subscriber Server(HSS) 5, a Serving Call State Control Function (S-CSCF) 6, and otherentities and networks as illustrated in FIG. 1.

As shown in FIG. 1, the P-CSCF 4, or generally a Policy Control Function(PCF), has a protocol interface (Go interface).with the GGSN whichsupports the transfer of information and policy decisions between apolicy decision point (PDP) and a policy enforcement point (PEP) in theGGSN (following COPS framework). The PCF may be co-located with theP-CSCF and is a logical policy decision element which uses standard IPmechanisms to implement Service-based Local Policy in the bearer level,enabling coordination between events in the SIP session level andresource management in the bearer level. The PCF makes policy decisionsbased on information obtained from the P-CSCF.

Generally, at PDP context activation (PDP—Packet Data Protocol), SGSN 2and GGSN 3 create a PDP context, containing information about theconnection (e.g. IP address, QoS, routing information, etc.). Eachsubscriber may activate several PDP contexts towards the same ordifferent GGSNs.

This invention proposes several different methods and systems for thecase of misbehaving. UEs 1.

A first embodiment is shown in FIG. 2. If the PDP contexts are notactivated (and/or the emergency session is not confirmed) within acertain time after attach, the SGSN 2 detaches the UE 1. A timer isprovided in the SGSN 2.

In detail, when the UE (MS) 1 initiates a procedure to the SGSN 2 instep 1 indicating a request to establish an emergency session, e.g. ifthe UE initiates attach with an emergency indication or with anemergency IMSI, the SGSN 2 starts an internal timer (step 2) set to anappropriate time interval such as 10 sec, or 30 sec. When the timerexpires without PDP contexts having been activated (and/or the emergencysession not being confirmed), the SGSN 2 detaches the UE 1 (step 3).

When on the other hand the PDP context activation is initiated and/orthe emergency session is confirmed before the expiry time of the timer,the timer is removed and the emergency session is continued in theproper way.

FIG. 3 shows another embodiment of the present invention, wherein the Gointerface is used to validate whether the session is actually anemergency session. The P-CSCF/PCF 4. indicates whether the session is anemergency session.

This indication can be sent when the PDP context is authorized againstthe session. If the session is not an emergency session even ifindicated in the PDP context parameters, the GGSN 3 rejects the PDPcontext activation.

The SGSN 2 stores information on otherwise unauthorized UEs and checksif the PDP context is rejected for such a UE. If this is the case, theSGSN 2 understands from the PDP context rejection that the UE 1 wasallowed to access the network just to setup an emergency session and thesession is not an emergency session. The SGSN 2 thus detaches the UE 1.An alternative solution is to introduce a clear indication from the GGSN3 to the SGSN 2 that the session is not an emergency session (e.g. witha cause code ‘requested service incorrect’),and thus the UE 1 is to bedetached. Also in this case, the SGSN 2 stores information on otherwiseunauthorized UEs and checks if the PDP context is rejected for such aUE.

In the embodiment of FIG. 3, the emergency session request is indicatedfrom UE (MS) 1 to the SGSN 2, and from SGSN 2 to GGSN 3 in steps 1., 2.(“PDP Context Req (Emergency Session Indication)”). In step 3., the GGSN3 communicates with the P-CSCF/PCF 4 for continuing with the emergencysession, e.g. by requesting PDP context authorization.

In step 4., the P-CSCF/PCF 4 informs the GGSN 3 that the requestedsession to be handled is not an emergency session (step 4), e.g. bydirectly sending respective information, or by returning an informationto the GGSN 3 e.g. on the type of the actual session requested fromwhich GGSN 3 can conclude that the session is not an emergency session.The GGSN 3 in such a case sends a message to the SGSN 2 (step 5) forcausing the SGSN 2 to stop continuing with the requested session. Such amessage may e.g. be a “Reject PDP Context Req” message with anindication “No Emergency Session”. The SGSN 2 may send this message tothe UE 1 (step 6). When receiving such a message, the SGSN 2 bars the UE1 from continuing with the session, e.g. by detaching it from thenetwork (step 7).

FIG. 4 illustrates another embodiment which comprises the feature ofrequesting detaching the UE (MS) 1 via HSS 5 (UMS/HLR) (HSS=HomeSubscriber Server; UMS=User Mobility Server; HLR=Home LocationRegister).

In the embodiment of FIG. 4, the P-CSCF/PCF detects service misuse instep 1. P-CSCF/PCF may detect service misuse e.g. if an unregistered UEwhich is allowed to establish only emergency sessions establishes asession which is not an emergency session. Alternatively, the P-CSCF/PCFmay detect service misuse when communicating with the GGSN at PDPcontext activation. The GGSN may receive information that the UE isallowed to establish only emergency sessions from the SGSN and mayindicate this to the P-CSCF/PCF. When the P-CSCF/PCF 4 detects servicemisuse, the P-CSCF/PCF indicates this to the S-CSCF 6 in step 2. TheS-CSCF 6 indicates, in a step 3, to the UMS of HSS 5 that the UE 1 hasto be deregistered/detached from the network. The UMS passes thisinformation to the HLR. The HLR initiates the detach procedure bysending, in step 4, a message, e.g. “Cancel Location” to the SGSN 2 forinstructing the SGSN 2 to detach the UE 1 from the network (step 5). Thesteps of HLR initiating the detach procedure as such, including step 4,is an existing procedure which is also known as HLR-initiated detach.This procedure is used here as a partial feature in the specific novelcontext of detecting and blocking a wrongful emergency session request.

A further embodiment is shown in FIG. 5 which involves UE (MS) 1, SGSN2, GGSN 3, and P-CSCF/PCF 4. In the embodiment of FIG. 5, the emergencysession request is indicated from UE (MS) 1 to the SGSN 2, and from SGSN2 to GGSN 3 in steps 1., 2. (“PDP Context Req (Emergency SessionIndication)”). Subsequently, the GGSN 3 communicates with the P-CSCF 4for authorizing the PDP context, as indicated by the double-headed arrowin step 3.

The PDP context may be used to carry traffic when the PDP contextactivation is accepted. The GGSN 3 can know and detect whether the UE 1misuses the PDP contexts by performing a traffic check (step 4). Forexample, the GGSN 3 checks that the traffic is carried only between theUE 1 and the authorized peer (e.g. the EC or MGW). The GGSN receivesinformation on the authorized peer at PDP context authorization. Asanother example, the GGSN 3 checks that the traffic is carried onlybetween the UE 1 and the P-CSCF. In the latter example, information onP-CSCF may be configured to the GGSN 3. All other traffic is dropped bythe GGSN 3 for allowing only emergency session handling. If the GGSN 3drops packets, this is an indication that the UE 1 is misusing the PDPcontext for a non-emergency session. The GGSN 3 can then inform the SGSN2, e.g. by deactivating the PDP context and/or by indicating the PDPcontext misuse in step 5. The SGSN 2 may then send this message to theUE 1 (step 6). The SGSN 2 can then detach the UE 1 as indicated in theabove embodiments (step 7).

While the invention has been described with reference to preferredembodiments, the description is illustrative of the invention and is notto be construed as limiting the invention. Various modifications andapplications may occur to those skilled in the art without departingfrom the scope of the invention as e.g. defined by the appended claims.

1. A method, comprising: receiving a session request from a userequipment, wherein the user equipment is permitted to initiate sessionsof a first type or types, but not permitted to initiate sessions of asecond type or types, the first type or types corresponding to anemergency session, and the second type or types not corresponding to theemergency session; starting a timer, set to a time interval, uponreceiving the session request from the user equipment for a session ofthe first type or types; checking whether a bearer is active for thesession of the first type or types within said time interval afterreceiving the session request, the bearer comprising a packet dataprotocol context; and detaching the user equipment from a network whendetecting that there is no bearer active for the session of the firsttype or types within said time interval after the attachment, whereinthe detaching the user equipment is requested via a server whendetecting that the requested session is a session of the second type ortypes.
 2. A method according to claim 1, further comprising: checking,via a supporting entity, whether one or more bearers are activated,and/or the session of the first type or types is confirmed, within atime interval after the attachment, wherein the supporting entity isconfigured to detach the user equipment when no activation orconfirmation has taken place within the time interval.
 3. A methodaccording to claim 2, wherein the supporting entity comprises a timerset to the time interval and configured to start timing when the userequipment attaches to the network.
 4. A method according to claim 1,wherein the server is a home subscriber server.
 5. A method according toclaim 1, wherein a serving function indicates to the server that theuser equipment has to be deregistered/detached from the network, theserver initiating a detach procedure by sending a message to thesupporting entity.
 6. An apparatus, comprising: at least one processor;and at least one memory, wherein the at least one processor and the atleast one memory provide at least the following: a timer configured tostart a time check of a time interval when a user equipment is attachedto a network when requesting a session of a first type or types, thefirst type or types corresponding to an emergency session, and thesecond type or types not corresponding to the emergency session; and acontroller configured to detach the user equipment from the network whenthere is no bearer active during the session within the time intervalafter the attachment of the user equipment, the bearer comprising apacket data protocol context, wherein the apparatus is configured torequest detaching the user equipment via a server when detecting thatthe requested session is a session of the second type or types.
 7. Anapparatus according to claim 6, wherein the controller is configured tocheck whether one or more bearers are activated, and/or the session ofthe first type or types is confirmed, within the time interval afterattachment, and wherein the controller is further configured to detachthe user equipment when no activation or confirmation has taken placewithin the time interval.
 8. An apparatus according to claim 6, whereinthe controller comprises a timer set to the time interval and configuredto start timing when the user equipment attaches to the network.
 9. Anapparatus according to claim 6, wherein the bearer is a packet dataprotocol context.
 10. An apparatus according to claim 6, wherein theserver is a home subscriber server.
 11. An apparatus according to claim6, further comprising: a serving function configured to indicate to theserver that the user equipment has to be deregistered/detached from thenetwork, the server being configured to detach the user equipment bysending a message to the controller.